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I. The Field Concept 

A. Introduction 

This report describes a portion of the STAR (Simulation of Tactical 
Alternative Responses) combined arms ground/air combat simulation model. 

STAR has been developed by students and faculty of the Operations Research 
Department at the Naval Postgraduate School as a tool for investigating 
ground/air combat. The model is programmed in SIMSCRIPT 1 1. 5, and a knowledge 
of that language is presumed in this report. Documentation of various other 
aspects of the model is given in references [1] - [5]. 

The purpose of the present report is to describe the Field Module 
of STAR. The Field Module is responsible for simulating vehicles encounter- 
ing minefields and other similar battlefield features. The remainder of this 
chapter will introduce the general concept of a field and the two types of 
actions related to fields. Chapter II will describe the data structures 
representing fields and the basic subroutines for creating fields and monitor- 
ing vehicle location with respect fo fields. Chapter III will discuss the 
modifications required in the existing STAR model to incorporate the Field 
Module. Finally, Chapter IV will consider the actions - the tactical responses 
that occur as a result of fields. 

B. Fields 

Definition: A field is an area on the battlefield which influences 

battle actions and hence battle outcome. 

Examples of fields include the following sorts of areas on the battlefield - 
some manmade and others naturally occurring: 
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Minefields - dug in or scatterable 

Engineered or natural obstacles 

River crossings 

Bridges 

Towns 

Forests 

Artillery trigger areas 

Residual nuclear or chemical effects areas. 

[21 

Forests are currently handled separately in the LOS module . The 
Field Module will be set up to be able to handle the remaining fields. 

Fields are represented in the STAR model as geometric areas 
overlaid on the terrain. The field module has the following functions: 

1. For each element in the simulation, monitor when the element 
enters/exits each field, 

2. When an element enters a field, perform designated actions 
(e.g. lower mine plow, reduce speed, change formation). 

3. When an element leaves a field, restore its condition to 
the normal state. 

4. Inside the field, perform designated actions (e.g. detonate 
mines) . 

5. Create fields at the beginning of the simulation and, if 
required, during the execution of the simulation. 

6. Destroy fields during the simulation if required. 

Since the Brigade level STAR model has the potential for modelling over a 
thousand elements, the field monitoring routines must be organized 
efficiently to avoid excessive overhead. 
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Field Actions 




Field 


actions are things that happen because vehicles 


encounter 


Typical actions which can be simulated include the following: 


1. 


Change speed. 




2. 


Change movement formation. 




3. 


Stop for a given time, then continue. 




4. 


Go into a hasty defensive posture. 




5. 


Detonate a mine. 




6. 


Lower or raise mine plow. 




7. 


Call for artillery or air strike. 




8. 


Mount or dismount infantry. 




9. 


Change movement path in attempt to bypass field. 


10. 


Attempt to clear obstacles or mines. 




11 . 


Attempt river crossing. 




12. 


Respond to nuclear effects such as radiation, 
blowdown . 


f i res , 



The field actions which occur for a given field will typically depend on 
the field type (e.g. minefield), on parameters of the field (e.g. mine 
density), and on the tactical situation (e.g. under fire?). In this 
section we discuss the general concept of field actions and how they are 
triggered. Implementation of specific actions will be covered in Chapter 
IV. 

There are two distinct kinds of field actions. Most field actions 
will occur immediately when vehicles cross the field boundaries (entering 
or exiting.) These actions, which we will call boundary actions , are 
easily triggered at the instant of entry or exit if the movement model can 
detect field boundary crossings. Other actions, however, occur somewhere 
inside the field. A mine detonation is the most obvious example. These 
actions are called internal actions . They are initiated by a field entry, 
but do not occur until the vehicle has moved into the field. To trigger 
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these actions, the simulation must measure the distance moved since 
field entry. 

It should be noted that neither type of field action can be 
conveniently modelled by scheduling SIMSCRIPT events. This is because a 
scheduled event occurs after a designated time interval has passed 
whereas field actions occur at designated locations . Since vehicles in 
STAR need not move at constant (or easily predictable) speed, it is 
usually impossible to predict when in time a field action will occur. 

Instead, the field module must monitor the location of each simulation 
element with respect to each field at every time of interest in the simu- 
lation. This is a task involving a potentially huge amount of computation. 

One approach to monitoring location with respect to fields would 
use the movement model. For each element, at each move increment, the 
procedure would loop over all fields, testing whether the element was in 
the field. If the in/out status changed from a previous move increment, 
then a boundary action would be performed. This approach was considered 
and rejected for several reasons: 

1. We suspect that it would be quite expensive to compute. 

2. The approach as described only locates field boundaries 
to the accuracy of the current move increment's length. 

(This could be overcome with additional computation). 

3. Internal actions cannot be easily handled using this approach. 

An alternative computational scheme is implemented in the 

current field module. For each element we compute and store the distance 
to the nearest field boundary action (entry, or exit) in the element attribute 
FLD.BDY.DIST(TANK) . Similarly, we store the distance (if any) to a pending 
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internal action in the attribute FLD. INT.DIST(TANK) . Then for each move 
increment these distances are decremented, When the remaining distance 
goes to zero, the appropriate action is triggered and the distance to the 
next action is computed. The main advantage of this process is that we 
need to loop over all fields only when a new distance is computed, and 
this will only be necessary when 

1. The vehicle's direction of movement changes. 

2. The vehicle encounters a field action. 

3. New fields are created or old ones destroyed. 

It also allows increased accuracy and handles boundary actions and internal 
actions using the same mechanism. 

Details of the computation are reserved for Chapter II. 

D. Overlapping Fields 

A major problem which must be considered in planning the Field 
module is the problem of overlapping fields. If an element can be in 
several fields simultaneously, ambiguities can arise as to the intended 
field actions. The geometry of the field module can recognize multiple 
field entries and exits in whatever order they occur without any problems. 
However, making the action routines smart enough to take combinations of 
fields into account is probably prohibitively complex. 

Unless special circumstances dictate otherwise, we plan to make 
the field action routines for a given field ignorant of whether the ele- 
ment is in other fields. Thus an element can safely be in two (or more) 
fields at one time as long as those fields influence different aspects of 
the element's behavior. If, however, field 1 increases an element's speed 
by 50% and field 2 decreases speed by 2 m./sec, then the effect of being in 
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both fields will be ambiguous. If the initial speed is 5 m/sec, then 
the resulting speed will be 5.5 m/sec if field 1 is entered first, or 
4.5 m/sec if field 2 is entered first. The user should be aware of such 
possible ambiguities and avoid them by careful definition of the fields 
required for a given scenario. 

Overlapping internal actions are also limited by the computational 
procedure of the Field module. Since an internal action is initiated 
(planned) when the field is entered, but doesn't actually occur until a 
designated distance into the field, we need to store this distance for 
each element (as an attribute called FLD.INT.DIST) . Since only one such 
internal distance is stored for each element, the model will not correctly 
simulate an element which is simultaneously in two different fields which 
both involve internal actions. 

These limitations are part of the current coding of the Field module. 
They doubtless could be overcome by more involved logic at an increased 
cost in coding effort, computer storage, execution time, and model clarity. 
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II. The Field Geometry Module for STAR 

A. Overview of the Module 

This chapter discusses the details of the geometric aspects of 
the field module. These include the definition and creation of fields 
and the process of monitoring field entry and exit. The Field module 
involves a new class of SIMSCRIPT temporary entities (FIELDS), along with 
several new subroutines for processing fields, which are discussed in 
this chapter. In addition, several existing routines must be modified to 
interface with the new module. (Chapter III). 

B. The Temporary Entity - FIELD 

In the STAR combat simulation, fields are modelled as elliptical 
overlays on the terrain. For purposes of field planning and model input 
data the shape of each field ellipse is described by the following para- 
meters (see Fi g. 1 . ) : 

XC.FLd\ X and Y battlefield coordinates of the 

YC.FLD J center of the ellipse 

SMAJ.FLD semi -major axis length 

SMIN.FLD semi-minor axis length 

ANG.FLD orientation angle in radians measured 

counterclockwise from east to the major axis. 

For computational purposes the boundary of the field is described by the 

quadratic equation 

PXX.FLD*(X-XC.FLD)**2 + PYY . FLD*( Y-YC . FLD)**2 
+ PXY.FLD*(X-XC.FLD)*(Y-YC.FLD) = 1.0 
Where the quadratic coefficients are defined as 

GANG = cos (ANG.FLD) 

SANG = sin( ANG.FLD) 

PXX. FLD = (CANG/SMAJ.FLD)**2 + (SANG/SMIN . FLD)**2 

PYY.FLD = (SANG/SMAJ.FLD)**2 + (CANG/SMIN . FLD)**2 

PXY. FLD = 2*SANG*CANG*(1 .0/SMAJ.FLD**2 - 1 .0/SMIN.FLD**2) 

7 




Figure 1. Field Shape Parameters 
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Each field is a SIMSCRIPT temporary entity in the entity class 
FIELD. The computational field parameters are stored as entity attributes 
as follows: 



XC.FLD(FIELD) 

YC.FLD(FIELD) 

PXX. FLD(FIELD) 
PYY.FLD(FIELD) 

PXY. FLD(FIELD) 



Defined as above - all are 
real variables 



In addition, each field has several other attributes: 



NAM.FLD 



TYP.FLD 

Pl.FLD ) 
P2.FLD I 
P3.FLD / 
P4.FLD J 



Sequential ID number in order 
of creation (Integer) 

Field type code (Integer) 

Real variables defining other 
field parameters (e.g. minefield 
density) which influence field action 
routines. May have different meanings 
for different field types. 



The distinction between the field type and the P1-P4 parameters 
is one of convenience. If two fields (say a scatterable minefield and a 
dug-in minefield) will both use the same field action routines, then they 



should be given the same field type, and the parameters should be used to 



distinguish between them. If, however, the actions triggered by one field 



are of a different sort than those resulting from the other field, then 
different field type codes should be used to describe them. We plan to 
have separate dedicated routines to trigger the actions for each separate 



field type. Each of these routines can use any or all of the P1-P4 para- 
meters. Four such parameters are initially provided for; ultimately this 



number may change. 



C. The FLD.SET 

For convenience in looping over the currently active fields, a system- 

owned set called the FLD.SET has been declared. Each field entity is 
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filed in the FLD.SET as the field is created. For as long as the field 
remains in the FLD.SET, the simulation will consider it to be an active 
field and will process it in all field module computations. If a field 
is removed from the FLD.SET, then the field module will ignore it. 

D. Routine FLD. CREATE 

Field entities are created by the FLD, CREATE routine. In a typical 
STAR run, this routine will be called several times by the FLD.INIT 
routine before the start of the simulation to initialize all fields that 
are in place at the start of the battle. Then during the simulation, 

FLD. CREATE may be called at any time to create dynamically emplaced fields 
(e.g. artillery scatterable mines). The routine assigns the next unused 
sequence number to the NAM. FLD attribute of the new field and returns this 
value so that, if desired, the calling program can refer to this specific 
field in the future. 

Given Arguments 



xc 


(real ) 


X coordinate of ellipse 


center 


YC 


( rea 1 ) 


Y coordinate of ellipse 


center 


SAMAJ 


(real ) 


semi -major axis length 




SAMIN 


( real ) 


semi -minor axis length 




ANGLE 


(real ) 


proper angle in radians 


from east to major axis 


TYPE 


(integer) 


field type code 




PI 


(real) ) 






P2 

P3 


(real) 1 
(real) ( 


field parameters 




P4 


(real ) ) 






Yielding Argument 






NAME 


(integer) 


sequential ID number of 


this field 


Local Variables 








SANG 


(real ) 


sin(ANGLE) 




GANG 


(real ) 


cos (ANGLE) 
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Global Variables 



FLOS. CREATED (integer) counter for number of fields created 

so far 



FIELD Entity Attributes 

XC.FLD See section B of the chapter for 

YC.FLD definitions - all are set by this 

PXX. FLD routine for the newly created field. 

PYY.FLD 

PXY. FLD 
NAM.FLD 
TYP.FLD 
PI .FLD 
P2.FLD 
P3.FLD 
P4.FLD 

Routines Called 

None 

Events Scheduled 
None 



Code See Figure 2. 



Brief Description 



Line 7 
Lines 8-14 

Lines 15-17 
Lines 18-22 
Line 23 



Creates the new field entity 

Set field attributes directly from 
the input arguments 

Assign the sequence number 

Compute the quadratic coefficients 

Files the field in the FLD. SET 



Use Enter with descriptive geometric field parameters. 

On exit the new field is created, and its computational 
parameters are set. 
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15 

16 

17 

18 

19 

20 

21 

22 

23 

24 
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ROUTINE FLD.CREfiTE 

” CREATE ONE FIELD AND SET ITS ATTRIBUTES 

GIVEN XC, YC,SAMAJ, SAM IN, ANGLE. TYPE, PI. P2.P3.P4 

YIELDING NAME 

NORMALLY MODE IS REAL 

DEFINE TYPE, NAME AS INTEGER VARIABLES 

CREATE A FIELD 

LET XC.FLD (FIELD) • XC 

LET YC.FLD(FIELD) » YC 

LET TYP*FLD(FIELD) * TYPE 

LET Pl.FLD(FIELD) = PI 

LET P2.FLD(FIELD) = P2 

LET P3.FLD (FIELD) - P3 

LET P4.FLD (FIELD) * P4 

ADD 1 TO FLDS. CREATED 

LET NAM. FLD (FIELD) * FLDS. CREATED 

LET NAME = FLDS. CREATED 

LET SANG = SIN. F (ANGLE) 

LET GANG » COS. F (ANGLE) 

LET PXX. FLD (FIELD) = (CANG/SAMAJ) *<«2 ♦ (SANG/SAMIN) x«2 
LET PYY. FLD (FIELD) * (SANG/SAMAJ) ♦ (CANG/SAMI N) ««2 
LET PXY. FLD (FIELD) = 2 nSANGxCANGm (1/SAMAJh«2 - 1/SAMINh«2) 
FILE THIS FIELD IN THE FLD. SET 

return 

END 



Figure 2. FLD. CREATE Routine 



12 



E. Routine FLD.INIT 

The FLD.INIT routine is called once by MAIN before the start of 
simulation. It reads cards describing the fields to be created before 
the simulation starts and calls FLD. CREATE for each such field. The 
FLD.INIT routine is then released from MAIN. The code in Figure 3 is 
self explanatory with the possible exception of line 9 which converts the 
angle from degrees (on the input card) to radians for the simulation. 

F. Routine FLD.DIST 

The FLD.DIST routine computes the distance to the nearest field 
boundary along an element's direction of movement. The resulting distance 
is stored in the element's FLD.BDY.DIST attribute. The distance is com- 
puted by solving the quadratic equation for the intersection of the ellipse 
boundary with the movement ray as folows: 

Let XCURjYCUR be the current element location and DX,DY the components 
of a normalized direction vector for the element, 
so DX = cos(element angle of movement) 
and DY = sin(element angle of movement). 

Then X = XCUR + S*DX 
Y = YCUR + S*DX 

give a parametric form of the movement path where the parameter S>0 
represents distance moved. 

The ellipse boundary is given by 

PXX(X-XC)^ + PYY(Y-YC)^ + PXY(X-XC) (Y-YC) = 1.0, (2) 

so plugging (1) into (2) gives a quadratic equation in S. If the 
quadratic has no real roots, then the movement path does not intersect 
the ellipse. If the roots are SI = S2, then the solution is a tangency 
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ROUTINE FLD.INIT 

CREfiTE fill FIELDS THfiT ARE IN PLACE AT THE START OF THE BATTLE 
NORHALLY NODE IS REAL 

DEFINE TYPE, NUN, I, NAME AS INTEGER VARIABLES 
USE UNIT 5 FOR INPUT 
READ NUH 

FOR I = 1 TO NUM DO 

READ XC, YC, SAHA J.SAMIN, ANGLE, TYPE, PI, P2,P3,P4 
LET ANGLE = ANGLE/RADIAN. C 

CALL FLD. CREATE GIVEN XC,YC,SAMAJ,SAM1N, ANGLE, TYPE, PI ,P2,P3,P4 
YIELDING NAME 

LOOP 

RETURN 

END 



Figure 3, FLDJNIT Routine 
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and we ignore it. Otherwise both roots exist and SI < S2. Negative 
roots correspond to boundaries already crossed, while positive roots cor- 
respond to boundaries which lie ahead, The routine loops over all fields 
and computes the smallest positive root. 

Given Arguments 



VEH 


( Integer) 


pointer to the element being moved 


Local Variables 






D 


(double) 


the smallest distance found so far 


DX 


(double) 


cos of element movement direction 


DY 


(double) 


sin of element movement direction 


XCUR 

YCUR 


(double) \ 
(double) j 


element's current location 


PXX 


(double) ] 




PYY 


(double) > 


field boundary coefficients 


PXY 


(double) J 




A 

B 


(double) ) 
(double) 7 


coefficients of the quadratic equation 
0 


C 


(double) j 


AS + BS + C = 0 


SI 


(double) 1 


roots of the quadratic (if they exist) 


S2 


(double) j 


with SI < S2 


Element Entity Attributes 




X. CURRENT (real)] 

Y. CURRENT (real)? 

DIR.OF.MVMT (real)) 


element's current location and angle 
of movement 


FLD.BDY.DIST (real) 


result of the computation - distance to 






nearest boundary 


Field Entity Attributes 




XC.FLD 

YC.FLD 


(real ) 1 
(real ) j 


field center coordinates 


PXX.FLD 

PYY.FLD 


(real )\ 
(real ) / 


field boundary coefficients 


PXY.FLD 


(real ) ) 




Routines Called 






None 






Events Scheduled 






None 
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Code See Figure 4 



Brief Explanation 



Line 9 


initializes D to + « 


Lines 11-14 


setup element location and direction 


Lines 15-42 


loop over each field in FLD.SET 


Lines 16-30 


compute SI , S2 if they exist, otherwise 
cycle to next field 


Lines 31-38 


find minimum positive value among SI, S2, D 
and save it in D 


Line 47 


stores the resulting D value (maybe + ») 
in the element's FLD.BDY.DIST attribute 



Use The FLD.DIST routine is called for each element in the simulation 
when the element is created. Whenever an element changes movement 
direction or crosses a field boundary the routine is called for 
that element to give a new FLD.BDY.DIST. Note that the distance 
finally returned is limited to 500m. for reasons of numerical 
roundoff error. This forces the model to periodically re-evaluate 
the FLD.BDY.DIST attribute. 
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ROUTINE FLD.DIST 

•• COMPUTE OlSTflNCE FROM VEH TO THE CLOSEST FIELD BOUNDARY 

•• ALONG CURRENT DIRECTION OF MOVEMENT 
GIVEN VEH 

DEFINE DX,DY,XCUR,YCUR.QX,QT,PXX,PYT,PXT,A,B,C,ARG,SQ,S1,S2,D AS DOUBLE 
VARIABLES 

DEFINE VEH AS AN INTEGER VARIABLE 

DEFINE FIELD AS AN INTEGER VARIABLE 
LET D » RINF.C 
IF FLDS. CREATED NE 0 

LET DX = C0S.F (DIR.OF.MVMT (VEHl) 

LET DY = SIN. F (DIR.OF.MVMT (VEHH 
LET XCUR = X. CURRENT (VEH) 

LET YCUR - Y. CURRENT (VEH) 

FOR EVERY FIELD IN FLD.SET DO 

LET QX = XCUR - XC. FLD (F lELD) 

LET QY = YCUR - YC. FLD (F lELD) 

LET PXX = PXX. FLD (FIELD) 

LET PYY = PYY.FLD(FIELD) 

LET PXY = PXY. FLD (FIELD) 

LET A = PXXmDX«h2 + PYY«DYnh2 + PXY«DXmDY 

LET B = 2«PXXmQX«DX ♦ 2xPYY«QY«DY + PXY« (QX«DY+QY«DX) 

LET C * PXXmQXmm2 + PYY«QY«h2 + PXYmQXnQY - 1.0 
LET ARG = B>o<2 - y.O^AxC 
IF ARG LE 0 
CYCLE 

ELSE 

LET SO = SORT. F (ARG) 

LET SI = - (B ♦ SO) / (2.0><A) 
let S2 = (SQ - B) / (2.0«A) 

IF SI GT 0.0 

IF SI LT D 

LET D = SI 
ALWAYS 
CYCLE 

ELSE 

IF S2 GT 0.0 AND S2 LT D 
LET D = S2 
ALWAYS 
••ENDIF 
••ENDIF 

LOOP 

IF D LT RINF.C AND D GT 500.0 
LET D = 500.0 
ALWAYS 
ALWAYS 

LET FLD.BDY.DIST (VEH) » D 
RETURN 

END 



Figure 4, FLD.DIST Routine 
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III. Interfacing The Field Routines v/ith STAR 

A. Overview of Changes Required 

Several changes in the existing STAR model code are required to 

implement the field module. For the most part these changes are simple 

and fairly obvious, but in one case (the MOVE routine) substantial effort 

was required. The following existing program segments were changed: 

PREAMBLE 

MAIN 

BL. CREATE 
RED. CREATE 
MOVE 

We detail the required changes in the remaining sections of this chapter. 
Familiarity with the basic STAR ground model is assumed (refs [l]-[5]). 



B. PREAMBLE 

1. New global integer variable FLDS. CREATED 

2. New system owned set FLD.SET 

3. New class of temporary entities FIELD with attributes 

NAM.FLD, XC.FLD, YC.FLD, PXX.FLD, PYY.FLD, PXY.FLD, 
TYP.FLD, Pl.FLD, P2.FLD, P3.FLD, P4.FLD 
(see Chapter II for definition and type). 

A FIELD may belong to the FLD.SET. 

4. New attributes for the TANK (or UNIT) temporary entity: 



5. 



FLD.INT.DIST 

FLD.BDY.DIST 

FLD.MO 

FLD.AKT 

FLD.INIT 



distance to pending internal action 

distance to nearest field boundary 

name of the field involved in any 
pending internal action 

code describing the kind of action 
for pending internal actions 

defined as a releasable routine. 
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C. MAIN 

1. Immediately following the call to RES. TERR, 

CALL FLD.INIT RELEASE FLD.INIT 

to create fields. 

D. BL. CREATE 

1. Immediately after the call to INIT.POS, 

CALL FLD.DIST (TANK) 

LET FLD.INT.DIST(TANK) = RINF.C 

to initialize field distance attributes. 

E. RED. CREATE 

1. Immediately after the call to INIT.POS, 

CALL FLD.DIST(TANK) 

LET FLD.INT.DIST(TANK)= RINF.C 

to initialize field distance attributes. 

F. MOVE 

The changes to the MOVE routine are central to the Field module, 
and are the most critical. In this section we explain these changes in 
detail. To aid in understanding the relation of these changes to the rest 
of the MOVE routine, we include a listing of the entire routine in Figure 
5, with changes flagged by "FLD in the right hand margin of the card. The 
reader is assumed to be familiar with the MOVE routine as documented in 
reference [4]. 

1. (Lines 157-161) Whenever a vehicle changes its direction of 
movement, the previously computed FLD.BDY.DIST is no longer 
valid, and must be recomputed by a call to FLD.DIST 
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2. (Lines 170-171) The distance limit for a move increment 
includes FLD.INT.DIST (to trigger internal actions) and 
FLD.BDY.DIST + 1 (to trigger boundary actions). The +1 is 
included to make sure that the boundary is actually crossed 
(by up to 1 meter) before the action is triggered. This 
prevents roundoff noise from triggering the same action more 
than one time. 

3. (Lines 215-227) At the end of each movement increment, if 
there are any fields in the battle, FLD.BDY.DIST and FLD.INT.DIST 
are updated. If either distance hits zero, the FLD.ACT routine 
is called to decode and perform the action. If as a result of 
the field action, the vehicle can no longer move, the call to 
MOVE is terminated. Finally, if we are within 50 meters of a 
boundary, the FLD.DIST routine is called to get a more accurate 
FLD.BDY.DIST. This extra call is required because of round-off 
errors on the IBM-360 where vehicle X and Y coordinates have 
about 6 significant digits on a battlefield which may be 100,000 
meters deep. 
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ROUTINE TO MOVE GIVEN VEH 
DEFINE K fiS RN INTEGER VRRIRBLE 
DEFINE SLOPE fiS fi RERL VRRIRBLE 

DEFINE REM. MOVE. TIME, DEL.X, DEL.Y, D.TO.MCP, RLPH, SRLPH, 

CRLPH, GRRD.X, GRRD.Y, SPD. LIMIT, RCCEL. LIMIT, DECEL. LIMIT, 

DIST. LIMIT, DEL. SPD, DIST.INCR, TIME.INCR RS RERL VRRIRBLES 
DEFINE DIST.REQ, TIME.REQ, ZERO. LEVEL RS RERL VRRIRBLES 
DEFINE X.DEST, Y.DEST, DIR, CX, CY, NX, NY, LX, LY, NLX, NLY, PX,PY, 
NPX, NPY, X.OFF, Y.OFF, D.TO.DEST RS RERL VRRIRBLES 
DEFINE THETR, CTH, STH RS RERL VRRIRBLES 
DEFINE VEH, FINRL RS INTEGER VRRIRBLES 

DEFINE MST, RT, NM, MCP.INC, LM, MCP, D.ON.RT RS INTEGER VRRIRBLES 
DEFINE FRKE.MCP RS RN INTEGER VRRIRBLE 
define I RND J RS INTEGER VRRIRBLES 
CHECKOUT VEH RLWRYS 

LET ZERO. LEVEL = 1.0 LET FINRL = 0 
LET MST = MV.STRTE (VEH) 

IF MST = 0 OR MST >= 4 RETURN 
ELSE 

IF MST EOURLS 1 

CRLL RT.SEL (VEH) 

LET MV.STRTE (VEH) = 2 
RLWRYS 

LET REM. MOVE. TIME = TIME.V - T.SPD(VEH) 

LET RT = ROUTE (VEH) 

LET D.ON.RT = DI R. ON. RT (VEH) 

LET FRKE.MCP = 0 

IF RT EQURLS 0 LET D.TO.MCP = RINF.C GO TO RNGLES 
ELSE 

* ’CONSISTENCY CHECK FOR POSSIBLE TURNRROUND 
IF RRER.STRRT (VEH) LT RRER. END (VEH) 

IF D.ON.RT EQ 0 GO TO NEW. MCP 

ELSE LET D.ON.RT = 0 

LET DIR.ON.RT (VEH) = 0 

LET K = DIM.F(R0UTE.DRTR(RT,h))/3 

LET MCP = NEXT. MCP (VEH) 

IF MCP EQ 0 LET NEXT . MCP (VEH) = 1 
ELSE IF MCP EQ K LET NEXT . MCP (VEH) = 0 
ELSE LET NEXT. MCP (VEH) = MCP + 1 
RLWRYS 
RLWRYS 

ELSE • ’RRER.STRRT GT RRER. END 

IF D.ON.RT EQ 1 GO TO NEW. MCP 

ELSE LET D.ON.RT = 1 

LET DIR.ON.RT (VEH) = 1 

LET K = DIM. F (ROUTE. DRTR (RT,m) ) /3 

LET MCP s NEXT. MCP (VEH) 

IF MCP EQ 0 LET NEXT . MCP (VEH) = K 
ELSE IF MCP EQ 1 LET NEXT . MCP (VEH) = 0 
ELSE LET NEXT. MCP (VEH) = MCP -1 

Figure 5. MOVE Routine 



21 



51 

52 

53 

5 ^ 

55 

56 

57 

58 

59 

60 

61 

62 

63 

6>4 

65 

66 

67 

68 

69 

70 

71 

72 

73 

74 

75 

76 

77 

78 

79 

80 

81 

82 

83 

84 

85 

86 

87 

88 

89 

90 

91 

92 

93 

94 

95 

96 

97 

98 

99 

100 



flLHfiYS 

fiLWfiTS 

flLWftYS 

'NEW.MCP* LET MCP = NEXT. MCP (VEH) LET NM = MCP « 3 

IF MCP EQUfiLS 0 ’’MOVE TO POSITION IN fiREfl.END 

IF POS. IN.PLT.fiREfi (VEH) EQUALS 0, CALL BEST . POS (VEH) ’’SETTING POS.IN.PLT.A 
ALWAYS 

LET 1 » PLT(VEH) LET K =• POS. 1 N. PLT . AREA (VEH) m 3 

FOR J = 1 TO DIM. F (POSITION (1 ,m,m) ) WITH POSl T 1 ON ( 1 , J, 1 ) EQUALS 
AREA. END (VEH) 

DO 

LET X.DEST = P0S1T10N(KJ,K-1) 

LET Y.DEST = POSITI ON (K J, K) 

LET DIR 5= POSITION (1,J,K-*1) 

LOOP 

LET D. TO. MCP = SQRT. F ( (X. DEST-X. CURRENT (VEH) ) + 

(Y.DEST-Y. CURRENT (VEH) ) ««2) 

IF D. TO. MCP LESS THAN ZERO. LEVEL, 

LET MV. STATE (VEH) = 4 
LET DIR.OF.MVMT (VEH) *= DIR 
LET PRI.DIR(VEH) * DIR 
LET SPD(VEH) = 0. 

LET FINAL = 1 
GO TO NEW.INCR 

ELSE 

GO TO DIRN.COMP 

ELSE 

IF FORM. CODE (VEH) EQUALS 0 ”G0 DIRECTLY TO NEXT MCP 

LET X.DEST = ROUTE . DATA (RT , NM-2) 

LET Y.DEST = ROUTE . DATA (RT , NM- 1 ) 

LET D. TO. MCP = SQRT. F ( (X. DEST-X. CURRENT (VEH) ) hm2 + 

(Y.DEST-Y. CURRENT (VEH) ) ««2) 

GO TO DIRN.COMP 

ELSE ’’MOVE ALONG ROUTE OFFSET BY FORMATION 

IF MCP EQUALS 1 AND D.ON.RT EQUALS 0 ’’TOWARD FIRST MCP 

LET NX = ROUTE. DATA (RT, 4) 

LET NY = ROUTE. DATA (RT, 5) 

LET LX = ROUTE. DATA (RT, 1) 

LET LY = ROUTE. DATA (RT, 2) 

LET I » ROUTE. DATA (RT, 3) 

ELSE 

LET K = DIM. F (ROUTE. DATA (RT,x) ) 

IF MCP EQUALS K/3 AND D.ON.RT EQUALS 1 ’’TOWARD LAST MCP GOING BACKWARD 
LET NX = ROUTE. DATA (RT,K-5) 

LET NY =* ROUTE. DATA (RT,K-4) 

LET LX * ROUTE. DATA (RT,K-2) 

LET LY = ROUTE. DATA (RT,K-1) 

LET I = ROUTE. DATA (RT,K-3) 

ELSE GO TO INTERNED 
ALWAYS 



Figure 5 (Continued). 
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RLWfiTS 

LET NLX «= NX-LX LET NLY = NT-LY 

IF I EQUALS 0, LET I * FORM. COOE (VEH) 

ALHRYS 

LET J = FORM. POS (VEH) x 2 
LET X.OFF = FORM. OFFSET (I, J-1) 

LET Y.OFF 1= FORM. OFFSET (I, J) 

LET THETR = RRCTRN. F (NLY, NLX) 

LET CTH = COS.F (THETR) 

LET STH * SIN. F (THETR) 

LET X.DEST = LX (X.OFF FOR. CHG. INT) xCTH - Y.OFFxSTH 

LET Y.OEST = LY + (X.OFF FOR. CHG. INT) xSTH + Y.OFF x CTH 

LET D.TO.MCP = SORT . F ( (X. DEST-X. CURRENT (VEH) ) x«2 (Y. OEST-Y . CURRENT (VEH) ) 

xx2) 

GO TO DIRN.COMP 

MNTERMED' ''TO HERE FOR INTERMEOIRTE MCP’S ON ROUTE 

LET CX X. CURRENT (VEH) LET CY = Y. CURRENT (VEH) 

IF O.ON.RT EQUALS 0 LET LM = NM - 3 

ELSE LET LM =» NM + 3 

ALWAYS 

LET NX = ROUTE. ORTA (RT,NM-2) 

LET NY ^ ROUTE. ORTA (RT.NM-l) 

LET LX = ROUTE. 0RTR(RT,LM-2) 

LET LY ROUTE. ORTA (RT,LM-1) 

LET NLX =* NX - LX LET NLY = NY - LY 

LET RLPH =- ( (CX-NX) xNLX + (CY-NY) xNLY) / (NLXxNLX NLYxNLY) 

LET PX = RLPH X LX ♦ (1. - RLPH) x NX 

LET PY = RLPH x LY ♦ (1. - RLPH) x NY 

LET NPX = NX - PX LET NPY = NY - PY 

LET I = ROUTE. DATA (RT,NM-^3x (0. ON. RT-1) ) 

IF I EQUALS 0, LET I = FORM. CODE (VEH) 

ALWAYS 

LET J - FORM. POS (VEH) x 2 
LET X.OFF = FORM. OFFSET (I, J-1) 

LET Y.OFF = FORM. OFFSET (I, J) 

LET D.TO.MCP = SORT. F (NPXxNPX + NPYxNPY) 

IF D.TO.MCP LESS THAN ZERO. LEVEL GO TO MCP. REACHED 
ELSE 

LET THETA = ARCTAN. F (NLY, NLX) 

LET CTH = COS.F (THETA) 

LET STH * SIN. F (THETA) 

LET RLPH = FOR.CHG.INT / D.TO.MCP 

LET X.DEST = PX RLPH x NPX + X.OFF x CTH - Y.OFF x STH 

LET Y.DEST = PY + RLPH x NPY Y.OFF x CTH X.OFF x STH 

LET D.TO.DEST = SORT. F ( (X. DEST-CX) xx2 + (Y.DEST -CY)x»<2) 

IF D.TO.DEST IS LESS THAN D.TO.MCP 
LET D.TO.MCP = D.TO.DEST 
LET FAKE. MCP = 1 
ELSE LET FAKE. MCP = 0 
ALWAYS 



Figure 5 (Continued), 
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•DIRN.COMP* 

IF D.TO.MCP IS LESS THAN ZERO. LEVEL, 
GO TO MCP. REACHED 

ELSE 

LET DEL.X = X.DEST - X. CURRENT (VEH) 
LET DEL.Y = Y.DEST - Y. CURRENT (VEH) 



LET DIR = DIR.OF.MVMT (VEH) "FLO 

LET DIR.OF.MVMT(VEH) = ARCTAN. F (DEL . Y , DEL . X) 

IF ABS.F (DIR-DIR.OF.MVMT (VEH) ) GT 0.02 ’ TLD 

CALL FLD.DIST (VEH) ”T0 COMPUTE NEW FLD.BDY.DIST FLO 

ALWAYS ”FLD 

•ANGLES' 



LET SALPH = SIN. F (DIR.OF.MVMT (VEH) ) LET CALPH = COS. F (DIR. OF . MVMT (VEH) ) 

•NEW.INCR' CALL ELEVG (X . CURRENT (VEH) , Y . CURRENT (VEH) ) YIELDING Z . CURRENT (VEH) , 
GRAD.X, GRAD.Y 

IF FINAL EQUALS 1, GO TO END. MOVE 
ELSE 

LET SLOPE = GRAD.X n CALPH GRAD.Y x SALPH 

CALL MOVE. LIMITS GIVEN VEH, SLOPE YIELDING SPD. LIMIT, ACCEL. LIMIT, DECEL. LIMIT 
LET DIST. LIMIT = MIN. F (D. TO. MCP, MAX. DI ST . INCR, "FLD 

FLD. INT.DIST (VEH) , (1 FLD. BDY. DIST (VEH) ) ) "FLO 

LET DEL.SPD= SPD. LIMIT - SPD (VEH) 

IF ABS.F (DEL. SPD) LT 0.1, 

"EASY CASE NO ACCELERATION -- 

LET DIST. INCR = REM. MOVE. TIME « SPD. LIMIT 
IF DIST. INCR IS GREATER THAN DIST. LIMIT, 

"MOVE STOPPED BY DISTANCE LIMIT 
LET DIST. INCR = DIST. LIMIT 
LET TIME. INCR = DIST. INCR / SPD. LIMIT 

ELSE 

"MOVE STOPPED BY TIME LIMIT 

LET TIME. INCR = REM. MOVE . T I ME 
ALWAYS GO TO MOVE. IT 

ELSE "HARD CASE -- ACCELERATION REQUIRED -- 

IF DEL. SPD IS LESS THAN 0, LET ACCEL. LIMIT = DECEL. LIMIT 
ALWAYS LET TIME.REQ = DEL. SPD / ACCEL. LIMIT 

LET DIST.REQ = SPD (VEH) mT I ME . REQ ♦ 0.5 « ACCEL. LIMIT m TIME.REQ ««2 
IF TIME.REQ IS GREATER THAN REM. MOVE . T I ME , 

"SPD. LIMIT CANNOTBE ATTAINED IN REMAINING TIME, SO CHANGE LIMIT 
LET SPD. LIMIT = SPD (VEH) ACCEL. LIMIT x REM. MOVE. T I ME 
LET DIST. INCR = SPD (VEH) x REM. MOVE. TIME + 0.5 x ACCEL. LIMIT x 
REM. MOVE. TIME xx 2 
ELSE "SPD. LIMIT CAN BE ATTAINED 

LET DIST. INCR = DIST.REQ ♦ (REM. MOVE . T IME - T I ME . REQ) xSPD. L I M I T 
ALWAYS 

IF DIST. INCR IS LESS THAN DIST. LIMIT. 

"MOVE WILL BE STOPPED BY TIME LIMIT 
LET TIME. INCR = REM. MOVE . T I ME 
LET SPD(VEH) = SPD. LIMIT 

"MOVE STOPPED BY DISTANCE LIMIT 

Figure 5 (Continued) . 
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LET DIST.INCR = DIST. LIMIT 
IF DIST. LIMIT IS LESS THAN OIST.REQ, 

LET TIME.INCR = (SORT. F (SPD (VEH) + >,flCCEL. LI MI T«0IST . L I MI T) 
-SPD (VEH) ) /flCCEL. LIMIT 
ADD TIME.INCR m ACCEL. LIMIT TO SPD (VEH) 

ELSE 

LET TIME.INCR = TIME. RED + (DIST. LIMIT-DI ST. RED) /SPD. LIMIT 
LET SPD (VEH) =SPD. LIMIT 
ALWAYS 
ALWAYS 

'MOVE. IT' SUBTRACT TIME.INCR FROM REM. MOVE . T I ME 
ADD DIST.INCR h CALPH TO X. CURRENT (VEH) 

ADD DIST.INCR m SALPH TO Y. CURRENT (VEH) 

SUBTRACT DIST.INCR FROM D.TO.MCP 
IF FLOS. CREATED GT 0 



SUBTRACT DIST.INCR FROM FLO. BOY . DI ST (VEH) "FLO 

SUBTRACT DIST.INCR FROM FLO. I NT . DIST (VEH) "FLO 

IF FLO. INT. DIST (VEH) LE 0.0 OR FLO. BOY. DIST (VEH) LE 0.0 "FLO 

CALL FLO. ACT (VEH) "FLO 

IF KKILL(VEH) EO 1 OR MKILL (VEH) EQ 1 "FLO 

LET FINAL = 1 - "FLO 

ALWAYS "FLO 

ALWAYS "FLO 



IF FLO. BOY. DIST (VEH) LT 50. D 
CALL FLO. DIST (VEH) 

ALWAYS 

ALWAYS 

IF REM. MOVE. TIME LT D.DU LET FINAL=1 
REGARDLESS 

IF D.TO.MCP IS LESS THAN ZERO. LEVEL. 

'MCP. REACHED' 

IF FAKE. MCP EQUALS 1 
LET FAKE. MCP = 0 
GO TO NEW. MCP 

ELSE 

IF MCP = 0 

LET FINAL = 1 
GO TO NEW. MCP 

ELSE 

IF DIR.ON.RT (VEH) EQUALS D "MCP NUMBERS INCREASE 

IF NEXT. MCP (VEH) EQUALS DI M . F (ROUTE . DATA (ROUTE (VEH) , m) ) /3 
LET NEXT. MCP (VEH) = 0 
GO TO NEW. MCP 

ELSE 

ADD 1 TO NEXT. MCP (VEH) GO TO NEW. MCP 

ELSE "MCP NUMBERS DECREASE 

IF NEXT. MCP (VEH) EQUALS 1 
LET NEXT.MCP(VEH) =0 
GO TO NEW. MCP 

ELSE 



Figure 5 (Continued) . 
25 



GO TO NEM.MCP 



251 SUBTRACT 1 FROM NEXT.MCP (VEH) 

252 ELSE GO TO NEM.INCR 

253 'END. MOVE’ LET T.SPD(VEH) = TIME.V 

254 RETURN 

255 END 



Figure 5 (Continued). 
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IV. Field Actions 

The final aspect of the Field module which we must discuss is the 
implementation of field actions. As indicated in Chapter I, field actions 
occur as a result of a vehicle encountering a field boundary. Actions 
which occur immediately are called field boundary actions . Actions which 
are planned for later occurrence are called field internal actions . 

A. Deciding Which Action to Perform 

When the FLD.ACT routine is called from the MOVE routine, it must 
decide which field action(s) to perform. Figure 6 shows a partial listing 
of a FLD.ACT routine. Details of particular actions are not included since 
they are quite dependent on the scenario plan for a given study. Examples 
of how typical actions might be handled are given in section B of this 
chapter. What this code segment does show is the procedure for deciding 
whether entry, i nternal , or exit actions should occur, and in each case, 
the field involved. 

If FLD. INT.ACT(VEH) has been decremented to zero, then a previously 
planned internal action should occur, (lines 4-11). The field for which 
this action was planned is indicated in the vehicle's FLD. NO attribute and 
the action type is given by the vehicle's FLD.AKT attribute. Note that at 
most one such action can be pending at any one time. A typical internal 
action is a mine detonation which would call POP. A. MINE to assess lethality 
and, if the vehicle survived, would initiate evasive action and plan the 
next detonation for this vehicle. 

If FLD.BDY.DIST(VEH) has been decremented to zero, then a boundary 
action should occur. A given move increment may, in some circumstances, 
cross more than one field boundary. Thus, instead of storing the field 
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ROUTINE FLD.flCT(VEH) SORTS OUT WHICH FIELD ACTIONS TO PERFORM 

DEFINE VEH, FIELD AS INTEGER VARIABLES 

DEFINE DX,DY,XCUR,TCUR,QX.QY,PXX,PXy,PTY,A,B,C,ARG,SQ.SKS2 AS DOUBLE VARIABLES 
IF FLD. INT.DIST (VEH) LE 0.0 

PRINT 1 LINE WITH NAME (VEH) ,X. CURRENT (VEH) ,Y. CURRENT (VEH) ,FLD. NO (VEH) , 
TIME.V AS FOLLOWS 

FLD INT ACT VEH=x«xx LOCN hhhhhh mmmmmm FIELD * hhhh TIME * hhhh 
« « 

'• HERE WE CRLL ROUTINES TO PERFORM INTERNAL ACTIONS 

« 4 

ALWAYS 

IF FLD.BDT.OIST (VEH) LE 0.0 

LET OX = COS.F (OIR.OF.MVMT (VEH) ) 

LET DY « SIN. F (OIR.OF.MVMT (VEH)) 

LET XCUR = X. CURRENT (VEH) 

LET TCUR = Y. CURRENT (VEH) 

FOR EVERT FIELO IN FLO. SET 00 

LET OX - XCUR - XC. FLO (FIELO) 

LET QT - YCUR - TC. FLO (FIELO) 

LET PXX = PXX. FLO (FIELO) 

LET PYY = PYY. FLO (FIELO) 

LET PXY = PXY. FLO (FIELO) 

LET A « PXX«0Xhk2 ♦ PYT«0Ynh2 ♦ PXYmOX«OT 

LET B ■ SmPXXmOXkOX ♦ 2hPYY»«QY»<DY ♦ PXYm (QXkOT*OT»«OX) 

LET C = PXX«QXx«2 + PYTmQYkm2 + PXThQXhOY - 1.0 
LET ARC “ B»<»<2 - U.OmRmC 
IF ARC LE 0 
CTCLE 

ELSE 

LET SO - SORT. F (ARC) 

LET SI » - (B + S0)/(2.0«A) 

LET S2 = (SO - B)/(2.0kA) 

IF 31 LE 0.0 ANO 31 GE -2.0 

PRINT 1 LINE WITH NAME (VEH) .XCUR, YCUR. NAM. FLO (FIELO) . 

TIME.V AS FOLLOWS 

FIELO ENTRY VEH^mmmm LOCN > mmmmmm mmmmmm FIELO ^ mmmm TIME ^ mmmm 
« « 

HERE WE CALL ROUTINES TO PERFORM FIELD ENTRY BOUNDARY ACTIONS 
ALWAYS 

IF 32 LE 0.0 ANO S2 GE -2.0 

PRINT 1 LINE WITH NAME (VEH) , XCUR. YCUR. NAM. FLD (FIELD) . 

TIME.V AS FOLLOWS 

FIELD EXIT VEH'^xxxx LOCN = hhhhhh mmmmmm FIELD =» mmmm TIME ^ mmmm 

* « 

HERE WE CALL ROUTINES TO PERFORM FIELD EXIT BOUNDARY ACTIONS 

% * 

IF NAM. FLO (FIELO) EQ FLO. NO (VEH) 

LET FLO. INT.OIST (VEH) = RINF.C 
LET FLO. NO (VEH) = 0 



Figure 6. Partial FLD, ACT Routine 
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51 I^LHATS 

52 flLMflTS 

53 ’’ENDIF 

51 LOOP 

55 nUHATS 

56 CALL FLD.DIST (VEH) 

57 RETURN 

56 END 



Figure 6 (Continued) . 
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number for a boundary action on the vehicle, we test each field for 
boundary crossing whenever FLD.ACT is called with FLD.BDY.DIST £ 0. The 
loop to implement this test is contained in lines 17 to 54. Note the 
tolerance of + 1 meter in lines 33 and 41. If this tolerance is decreased, 
some field entries or exits may be missed. 

Regardless of the actions triggered in FLD.ACT, the FLD.BDY.DIST 
is recomputed prior to return to set up the next boundary crossing. 

B. Implementing Some Typical Actions 

In this section we provide suggestions for implementing some pos- 
sible field actions. In many cases, an action performed on entering a 
field must be paired with a complementary action on exit which restores 
the vehicle to its previous state. This requires either saving the previous 
state for those attributes affected by the field or having a default back- 
ground state to which exiting vehicles return. 

The choice of field action to perform may, in some cases, depend 
on the type of "vehicle" encountering the field - an obstacle that totally 
stops wheeled vehicles may merely slow tanks and may be no hindrance at all 
for dismounted infantry. In this section we assume that the choice of 
actions to perform will be determined by the scenario writers and tacticians. 

1 . Change Speed 

A frequent result of entering a field is a change in speed (e.g. 
for an obstacle field). In this section we discuss speed changes which 
do not completely stop the vehicle. Simply changing the vehicle's SPD 
attribute on field entry will NOT suffice, because this attribute is reset 
at every move increment based on the results of a call to routine MOVE. LIMITS. 
One way of implementing a speed change would be to define a new vehicle 
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attribute FLD.SPD.FAC the field speed factor for the vehicle. When the 
vehicle is not in any field, FLD.SPD.FAC assumes a background value of 1.0. 
On field entry the FLD.ACT routine would set FLD.SPD.FAC to a value 
greater than 1.0 for a speed increase and less than 1.0 for a speed 
decrease. (The value would be one of the field parameters PI - P4). The 
MOVE. LIMITS routine would include FLD.SPD.FAC in its computation of 
vehicle target speed for each move increment. On field exit, FLD.ACT sets 
FLD.SPD.FAC back to 1.0. 

2. Stop for T Seconds 

To simulate a brief delay on field entry, the FLD.ACT routine 
can simply set the vehicle's MV. STATE to 3 (Stop along route). The vehicle 
will stop as soon as it is physically. possible. For a longer delay, we 
probably also want to set the vehicle's DEFNUM to simulate taking advantage 
of available cover. In either case, once the vehicle is stopped it will 
not trigger further field action. To get the vehicle started again after 
T seconds (a field parameter), a new event must be scheduled by the field 
entry routine. No field action is required on field exit. Similar comments 
apply to the hasty defense action. 

3. Response to Minefields 

A variety of actions may be appropriate for simulating a vehicle 
encountering a minefield. The first question which must be asked is whether 
the vehicle notices the minefield; Several cases can occur: 

a) Minefield detected on entry - Then the field entry 

action routine can initiate any desired vehicle responses 
and will plan an internal mine detonation action. 
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b) Minefield not detected - Then the field entry action 
routine only plans the internal mine detonation action, 
and the vehicle simply drives on. When the first deto- 
nation occurs, the minefield is assumed detected and 
appropriate responses are taken by the detonating vehicle 
and other vehicles in his immediate unit. 

c) Minefield detected prior to entry - A clearly visible 
field can be modelled by two concentric field ellipses. 
Entering the larger ellipse triggers the field detection 
and any responses thereto. Entering the smaller ellipse 
initiates mine detonation actions. 

Given that a vehicle has detected the minefield, several actions 
may be appropriate for it and for other vehicles in its immediate unit 
(perhaps platoon). If mine plows or rollers are available, they may be 
used (vehicle PLOW.COND attribute). This probably requires a brief stop. 
Vehicles without plov/s may line up behind those with plows (a formation 
change). The resulting unit will move slower while plowing (speed change). 

A more difficult action is an attempt to bypass the field. This 
would involve creation of special routes for moving around the field and 
has not been worked out in detail. 

On field exit, if we assume that the vehicle(s) can detect the exit, 
the above actions can be cancelled (perhaps involving another brief delay). 
If the exit is not detectable, then concentric ellipses could be used to 
delay the change back to a normal condition until after the field has been 
left. 
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4. Mine Detonation 

When a vehicle enters a minefield, the field boundary action 
is responsible for planning a mine detonation and storing this as the 
internal action for the vehicle. The distance that the vehicle will move 
before detonating a mine can be determined using a random draw from a 
distribution whose parameters are influenced by 

a) minefield density 

b) vehicle geometry (e.g. track width) 

c) mine detectability 

d) whether vehicle is in a cleared path 

(e.g. following a vehicle with a plow) 

This distance is used for the vehicle's FLD.INT.DIST attribute. If the 
vehicle travels this far through the field before encountering the exit 
boundary, then a field internal action is triggered. This action should 
assess the lethality of the mine, and, if the vehicle can still move, should 
plan the next detonation. 

As discussed in 3) above, if the minefield is not detectable, then 
the first detonation in a platoon or company might trigger responses from 
all vehicles in that unit. 

5. Call for Artillery or Air Strike 

One possible use for field ellipses is to represent pre-planned 
artillery or close air support trigger areas. The presence of a threshold 
number of enemy vehicles in the area can be used to initiate requests for 
artillery or air missions. Implementing this concept using fields calls for 
establishing a counter for each such field to keep track of the number of 
enemy inside the field. On field entry, the counter is incremented, and 
perhaps a mission request is initiated. On field exit the counter is 
decremented. 33 



other possible uses for the Field module will no doubt become 
apparent in the future. Because of the great variety of possible combin- 
ations of the various actions, actual implementation of the actions must 
await guidance, 
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The STAR field module. 
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